Communications between source and destination nodes over ATM systems, or networks, require end-to-end virtual circuits and/or virtual paths. To establish the virtual circuits and virtual paths, network nodes that are to be included therein exchange a series of call setup and acknowledgment messages. The source node, that is, the node that initiates the call on the network, sends over the ATM network a call setup message that identifies the intended destination for the call and the requirements of the connection, such as quality of service, and so forth. The ATM network then forwards the call setup message hop-by-hop, that is, node-by-node, over the network to the node that communicates directly with the destination, that is, to the destination node.
When a node receives a call setup message, the node determines if it can handle the call based on the connection requirements specified in the message. If the node cannot handle the call, the node returns a rejection message. Otherwise, the node sends an appropriate acknowledgment message back to the previous node on the route, and forwards the call setup message to a next node on the route. The call setup message continues through the nodes on the route until it reaches the destination node, which forwards call setup information to the intended destination station, as appropriate. If the destination node accepts the call, the destination node sends a connect message back along the route to the source node. The source node then sends a connection acknowledgment message to the destination node, to establish the end-to-end connection.
The call setup operation requires that each included node individually (i) process the call setup message, (ii) send back to the previous node an appropriate acknowledgment message to indicate receipt of the call setup message, and (iii) forward the call setup message to the next node. Accordingly, the time it takes to establish the call depends directly on the number of nodes included in the connection.
Recently, SONET rings have been incorporated into ATM systems, such that traffic in the form of ATM cells and frames can be sent over the ring. In a ring-based network, traffic between two nodes on the ring is routed over a primary ring and, if a failure should occur in a primary ring, the traffic is re-routed over a secondary ring. If the routes are over redundant rings, which pass traffic simultaneously in opposite directions, the system is commonly referred to as a xe2x80x9cunidirectional ring.xe2x80x9d
When a destination node or a source node is on the unidirectional SONET ring, the associated virtual path includes all of the nodes on the ring. Accordingly, each node on the ring must separately processes the call setup message, and the time to establish the connection is correspondingly lengthened by the number of nodes on the ring.
An improved SONET or ATM ring operates in accordance with a call setup procedure in which a single node on the ring, referred to herein as the xe2x80x9chub node,xe2x80x9d simultaneously (i) processes network call setup information from and provides call setup information to the network, and (ii) controls the call setup operations of the nodes on the ring. An end-to-end connection which includes an end node that is on the ring can thus be established over the ring in the time it takes to include the hub node and the end node in the connection, regardless of the number of nodes on the ring.
More specifically, when a call originates from a source node that is on the ring, the node directs a call setup message to the hub node. The hub node then acknowledges receipt of the call set up message and determines if there is sufficient bandwidth available on the ring for the call. If so, the hub node passes the call setup message to the ATM network, and simultaneously multicasts call setup information to each of the nodes on the ring. While the call setup message is progressing over the ATM network in a conventional manner, the nodes on the ring simultaneously set up the associated virtual path and/or virtual circuit over the ring and send back connection information to the hub node. If one or more of the ring nodes do not respond to the call setup information, the hub node may retry the call set up and/or initiate ring protection switching, as appropriate.
When the hub node receives a call acknowledgment message or a message indicating that the call has been rejected, the hub node forwards the message over the ring to the source node. If the call has been rejected, the hub node also multicasts an instruction to all of the nodes on the ring, directing them to tear down the associated virtual circuit and/or virtual path. If the call has instead been accepted, the source node establishes the end-to-end connection by sending a connect acknowledgment message to the destination node.
When the hub node receives a call setup message that is directed to a destination node which is part of the ring, the hub node determines if there is sufficient bandwidth available on the ring to handle the call. If so, the hub node sends an appropriate acknowledgment message back to the previous node on the route and forwards the call setup message to the destination node. The hub node also multicasts call setup information to all of the nodes on the ring, instructing them simultaneously to set up a virtual circuit and/or virtual path for the call.
In response to the instructions from the hub node, the ring nodes establish the associated virtual circuit and/or virtual path. If the destination node ultimately rejects the call, the hub node sends an appropriate call rejection message over the network to the source node and instructs the ring nodes to tear down the associated virtual circuit and/or virtual path. Otherwise, the destination node sends back a call acknowledgement message to the source node and the nodes on the ring participate in the end-to-end connection. All of the ring nodes are thus included in the connection in essentially the time it takes to include the hub node and end node.